home *** CD-ROM | disk | FTP | other *** search
/ Amiga Developer CD 2.1 / Amiga Developer CD v2.1.iso / Reference / Amiga_Mail_Vol1 / BootExpCon / IOSpace < prev    next >
Encoding:
Text File  |  1999-10-27  |  4.1 KB  |  129 lines
  1. (c)  Copyright 1989-1999 Amiga, Inc.   All rights reserved.
  2. The information contained herein is subject to change without notice, and 
  3. is provided "as is" without warranty of any kind, either expressed or implied.  
  4. The entire risk as to the use of this information is assumed by the user.
  5.  
  6.  
  7.                
  8.        Using the IO Space In Time Critical Applications
  9.  
  10.                            
  11.             by Robert V. Welland
  12.  
  13.  
  14. Preface
  15.  
  16. This document is directed at hardware designers who are intending
  17. to use the IO space in a time critical way.  An example of such
  18. an application would be a hard disk controller with a disk buffer
  19. in the IO space.  This engineering update is relevent to any
  20. hardware developer who is intending to use the IO space (E90000-
  21. EFFFFF) in a real-time manner.  For example if you are going to
  22. put a disk buffer into this space and want to read from it
  23. quickly, then this document concerns you.  
  24.  
  25. Introduction
  26.  
  27. In certain display modes the A2000 may not give reliable real-
  28. time response to devices in the auto-config and IO space
  29. (E80000-EFFFFF) when the designer relies on the traditional DTACK
  30. mechanisms (i.e either generating XRDY or allowing the system to
  31. generate DTACK automically).  In order for the designer to get
  32. reliable real-time response she will have to generate DTACK on
  33. board.  The designer will have to use OVR in order to gain
  34. control of the DTACK line and then assert DTACK.
  35.  
  36. Generating DTACK
  37.  
  38. Their are two things the designer must do to generate DTACK:
  39.  
  40. 1. Generate OVR (override).
  41.  
  42. 2. Generate DTACK.
  43.  
  44. To make this discussion simpler we will assume that there is a
  45. board select signal (AM) that is an address decode of the space
  46. allocated during auto-config.  The following PAL equations (in
  47. CUPL form) demonstrate the generation of DTACK.
  48.  
  49. /* Inputs */
  50.  
  51. /* Address strobe from the 68000 */
  52. PIN xx !AS;
  53.  
  54. /* Board address match */
  55. PIN xx !AM;
  56.  
  57. /* DTRACK enable signal from board */
  58. PIN xx !DTACKEN;
  59.  
  60. /* Outputs */
  61.  
  62. PIN xx !DTACK; /* DTACK */
  63. PIN xx !OVR; /* OVR _ override */
  64.  
  65. /* Equations */
  66.  
  67. /* Assert OVR whenever our board is selected */
  68. OVR = AM & AS;
  69.  
  70. /* Enable OVR whenever our board is selected */
  71. OVR.oe = AM & AS;
  72.  
  73. /* Assert DTACK whenever our board is selected and DTACKEN is
  74. asserted
  75. */
  76.  
  77. DTACK = AM & AS & DTACKEN;
  78.  
  79. /* Enable DTACK whenever our board is selected*/
  80. DTACK.oe= AM & AS;
  81.  
  82. Note that DTACKEN must be asserted at the moment when XRDY would
  83. usually be deasserted.  If you want one wait state DTACK would be
  84. asserted after the falling edge of S4 (the edge DTACK gets
  85. sampled on).  Remember that the the 68000 is asynchronous so it
  86. will automatically sync DTACK internally.  This can make DTACK
  87. generation much easier.
  88.  
  89. A Few Notes On OVR
  90.  
  91. Commodore is generally cautious about the use of OVR.  The reason
  92. for this is that it has been mis-used in the past.  I would like
  93. to clarify why we are cautious.
  94.  
  95. Uncontested Accesses
  96.  
  97. OVR tri-states the DTACK signal.  In the above usage that is ALL
  98. it will do.  The reason for this is that any access to our space
  99. is uncontested.  Ownership of such aspace has been given to one
  100. device during auto-configuration.  This means that all other
  101. devices on the bus should be ignoring this cycle (i.e. they will
  102. not try to respond).  In fact if they do, a collision will occur and
  103. the spec says that BOTH devices are supposed to get off the bus
  104. and generate bus error (BERR).  This should never happen
  105. however.  
  106.  
  107. Contested Accesses
  108.  
  109. Generating OVR outside of the expansion, IO, or auto-config space
  110. (200000-9FFFFF, E90000-EFFFFF, and E80000-E8FFFF respectively)
  111. can lead to disaster.  This is because you are contending with
  112. some other device for this cycle.  The results will be
  113. unpredictable.  For example if you generate OVR in the area of
  114. FC0000 you will be in contention with the ROM.  What we are
  115. getting at is the following law:
  116.  
  117. OVR does not give you exclusive access to the bus
  118.  
  119. A corollary to this law would be:
  120.  
  121. Any time you come in contention with another device for the bus,
  122. regardless of the state of OVR, unpredictable things will occur.
  123.  
  124.  
  125. Summary
  126.  
  127. If you are going to use IO space in a time critical manner, use
  128. OVR and DTACK instead of XRYD.  Never try to use OVR to gain
  129.